Некоторое время назад мы писали про аддон VMware vSphere Bitfusion (он интегрирован в vSphere Client как плагин), который позволяет оптимизировать использование графических процессоров GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может применяться для рабочих нагрузок задач AI/ML (например, для приложений, использующих PyTorch и/или TensorFlow).

Ключевой особенностью Bitfusion является возможность динамической привязки GPU к любой машине в датацентре, по аналогии с тем, как вы привязываете к ней хранилище.

На днях VMware выпустила интересный документ "VMware vSphere Bitfusion Performance Best Practices Guide", в котором описаны лучшие практики по использованию данного продукта.

В документе описаны следующие аспекты:

• Какое оборудование (GPU) следует использовать
• Требования к программному обеспечению
• Рекомендуемая сетевая конфигурация и настройки
• Настройки Bitfusion OVA
• Прочие настройки разного плана - BIOS, NUMA, настройки клиента и т.п.
• Частичное использование GPU в процентах
• Утилита Bitfusion Health Check Utility для отслеживания состояния кластеров

Whitepaper небольшой, всего 15 страниц, но зато он практически не содержит воды.

На сайте проекта VMware Labs появились обновления сразу трех интересных утилит. Давайте посмотрим, что там появилось нового:

1. Обновление FlowGate 1.1.2

Напомним, что FlowGate представляет собой средство для агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations). 

Давайте посмотрим, что нового в версии FlowGate 1.1.2:

• Добавлена поддержка шасси (Chassis) в API-интерфейсе
• Добавлены данные PDU phase
• Обновлена версия Springboot с 1.4.7 на 2.3.7

Скачать FlowGate 1.1.2 можно по этой ссылке.

2. Новая версия Demo Appliance for Tanzu Kubernetes Grid 1.1.3

Напомним, что это виртуальный демо-модуль, с помощью которого администраторы платформ vSphere и Kubernetes могут протестировать инфраструктуру контейнеризованных приложений в виртуальных машинах.

Что нового в версии 1.1.3:

• Поддержка последнего релиза TKG 1.1.3
• Поддержка рабочего процесса апгрейда TKG Workload Cluster на K8s 1.17.9 с версии 1.18.6
• Утилита TKG Crash Diagnostic utility (для отладки падений) в составе виртуального модуля
• Утилита Helm (3.2.4), включенная в состав модуля
• Обновленные версии Harbor (1.10.3), Docker Compose (1.26.2), Kubectl (1.18.6), Octant (0.14.1) и TMC (d11404fb) CLI в составе виртуального модуля
• Сценарий PowerCLI для автоматизации проверок запуска TKG на VMware Cloud on AWS

Скачать Tanzu Kubernetes Grid 1.1.3 можно по этой ссылке.

3. Обновление VMware Machine Learning Platform 0.3

Эта платформа предоставляет инженерам по работе с данными различные возможности в области Data Science в рамках виртуальной инфраструктуры.

Что нового появилось в обновлении vMLP 0.3:

• Федерация сервисов на базе FATE
• Обновленная версия Istio 1.4.9
• Обновленная версия Horovod 0.19.2
• Апгрейд основных компонентов (MLflow 1.10.0, Pandas 1.0.3 и других)
• Улучшения стабильности
• Обновления документации

Скачать vMLP 0.3 можно по этой ссылке.

Как многие из вас знают, у компании StarWind, выпускающей лучший продукт Virtual SAN для создания программных iSCSI хранилищ под виртуализацию, есть и программно-аппаратный комплекс HyperConverged Appliance (HCA). Чтобы управлять этим решением в контексте всей инфраструктуры, существует продукт StarWind Command Center, на который мы сегодня посмотрим.

На днях компания Gartner обновила свой магический квадрант, касающийся расстановки сил среди решений для резервного копирования и восстановления данных современных датацентров (Data Center Backup and Recovery Solutions).

Давайте взглянем на Magic Quadrant для Data Center Backup and Recovery Solutions 2020:

И сравним его с квадрантом прошлого года, о котором мы писали вот тут:

Уже четвертый год подряд занимает в этом исследовании место лидера, а в этом году вырвалась на первое место по критерию способность реализации (ability to execute). Gartner отмечает следующие сильные стороны продуктов Veeam:

• Monitoring, reporting and diagnostics — средства Veeam Intelligent Diagnostics обнаруживают проблемы с производительностью и некорректными конфигурациями, которые можно автоматически исправить с помощью решения Veeam ONE.
• Licensing portability — опция Veeam Universal License позволяет гибко переназначать лицензии между гипервизорами, а также физическими и виртуальными средами, расположенными on-premise или в облаке.
• Comprehensive Microsoft Exchange and Office 365 support — бэкап и гранулярное восстановление окружений Microsoft Exchange, Microsoft SharePoint и Office 365 из единой точки в рамках унифицированного процесса.

Более подробно о решении Veeam Availability Suite можно узнать по этой ссылке. Бесплатную пробную версию продукта Veeam Backup and Replication для VMware vSphere и Microsoft Hyper-V можно скачать вот тут.

Четыре года назад мы публиковали табличку, которая показывает соответствие билдов различных продуктов VMware их официальным версиям (а до этого мы публиковали табличку 6 лет назад).

С тех пор много чего изменилось, в том числе добавились новые продукты, поэтому ниже таблица с нужными ссылками для соответствующих продуктов и датами релизов:

Все перечисленные ссылки агрегированы в KB 1014508.

На этой неделе в подразделении VMware Education Services две важных новости - во-первых, компания выпустила сертификационный экзамен Professional VMware vSphere 7.x Exam (2V0-21.20), который необходим для основной сертификации VMware Certified Professional - Data Centre Virtualisation certification (VCP-DCV 2020), посвященный версии платформы VMware vSphere 7. Он уже доступен для регистрации, а подробное описание вы можете найти вот тут.

Сдать этот экзамен вы можете онлайн (но под наблюдением) через сайт Pearson VUE.

Вторая важная новость - это то, что теперь сертификации Data Centre Virtualisation certification (VCP-DCV 2020) и Network Virtualization 2020 (VCP-NV 2020) не требуют сдачи теста Foundations Exam, а лишь прохождения соответствующих треку сертификации курсов.

Для того, чтобы не сдавать этот экзамен просто выберите пункт no VCP certifications (Foundations exam not required) в разделе Certification Path:

Удачной сдачи экзамена!

Не так давно мы писали о том, как работает обновленный механизм балансировки нагрузки VMware DRS на новой версии платформы VMware vSphere 7. Напомним, что механизм DRS был полностью переписан, так как его основы закладывались достаточно давно.

Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом (на базе расчета стандартного отклонения по производительности), то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин. Теперь же механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness), отражающий удовлетворение потребности виртуальной машины в свободных ресурсах.

В документе "Load Balancing Performance of DRS in vSphere 7.0" компания VMware наглядно демонстрирует ситуации в которых новый DRS отрабатывает лучше старого. Давайте на них посмотрим.

Пример 1 - хост с отклонением нагрузки от большинства

В старом DRS, работающем по принципу выравнивания нагрузки в кластере на базе анализа стандартного отклонения загруженности хостов в рамках определенного порога, могла возникнуть вот такая ситуация, когда DRS не требовалось предпринимать никаких действий по выравниванию нагрузки, хотя они, очевидно, требовались:

Новый DRS работает на базе анализа ресурсов для каждой виртуальной машины и будет перемещать их средствами vMotion, пока не достигнет максимальной доступности ресурсов для каждой ВМ. В точно таком же случае, как описано выше, это приведет в итоге к более сбалансированной ситуации:

Пример 2 - неравномерная загрузка хостов в кластере

В старом DRS был порог по дисбалансу в кластере, и если он не превышен - то механизм балансировки не запускался. Это могло приводить к образованием групп хостов с разными уровнями средней загрузки процессора и памяти:

В ситуации с новым DRS ситуация в итоге, опять-таки, получается более справедливая:

Также полезной оказывается метрика DRS Score (она же VM Hapiness), которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.

Если все машины чувствуют себя "комфортно" на всех хостах, то DRS Score оказывается максимальным:

Если подать нагрузку на пару хостов ESXi, то их средний DRS Score падает, а на дэшборде указывается число машин, для которых рассчитаны низкие уровни DRS Score:

После того, как DRS обработает эту ситуацию, нагрузка на хосты выравнивается, а значение DRS Score увеличивается:

В документе еще много чего интересного - читайте.

Наверняка не все из вас видели новость компании VMware о том, что теперь релизы новых бета-версий платформы VMware vSphere будут происходить в рамках программы vSphere Continuous Beta.

Что это значит для администраторов?

Переход на Continuous Beta означает, что обновленные билды с новыми фичами vSphere будут выкладываться и обновляться на VMware Communities по ссылке выше постоянно, без длинных промежутков между ними.

Новая функциональность в этих билдах не будет привязана к конкретной версии vSphere, а администраторы смогут дать фидбэк по различным возможностям продукта. На базе пользовательского фидбэка будет уже формироваться список фич, которые будут включены в тот или иной релиз платформы.

Кстати, после скачивания и того, как вы зарегистрируетесь в бета-программе, вас "в нагрузку" попросят выполнить определенные задачи по тестированию неких блоков функциональности. Также вам будет предоставлен доступ в Beta Community, где вы сможете обсудить свой опыт тестирования платформы и внести предложения. Там же можно напрямую общаться как с техническими специалистами VMware, так и с командой технического маркетинга, которая отвечает в том числе за включение фич в релиз.

Ну и самое главное - новая бета-версия VMware vSphere уже ждет вас на портале программы. Переходите по этой ссылке, чтобы зарегистрироваться в VMware vSphere Continuous Beta Program.

На днях компания VMware выпустила обновления сразу трех интересных утилит для виртуальной инфраструктуры на сайте проекта VMware Labs. Давайте посмотрим, что там интересного.

1. Обновился мобильный клиент vSphere Mobile Client до версии 1.13

Тут появилось не так много нового, но все же:

• Страница информации о датасторе - Datastore details page (туда можно перейти со страницы виртуальной машины)
• Исправлена ошибка с соединением к консоли ВМ отдельного хоста ESXi
• Исправлена ошибка, возникавшая при переключении между серверами

Скачать vSphere Mobile Client 1.13 можно по этой ссылке. О прошлой версии можно почитать у нас тут.

2. Обновилось средство App Volumes Entitlement Sync до версии 4.1

Оно позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.

Из нового:

• Можно получить версию App Volumes через API с возможностью получения номера билда
• Версия App Volumes 2006 и более поздняя имела проблему с Entitlement Sync 4.0 при возвращении строкового значения

Скачать App Volumes Entitlement Sync 4.1 можно по этой ссылке. Напомним, что про предыдущую версию Entitlement Sync 4.0 мы рассказывали вот тут.

3. Новая версия Power vRA Cloud 1.3

Напомним, что это средство позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. 

Что появилось нового:

• 4 новых командлета для VMC (VMware Cloud)
• 5 новых командлетов для AWS
• Поддержка Powershell 7 on Windows
• Исправления ошибок

Скачать Power vRA Cloud 1.3 можно по этой ссылке. О возможностях версии 1.1 можно почитать у нас вот тут.

Компания NAKIVO, выпускающая решения для резервного копирования и защиты данных виртуальной инфраструктуры, выпустила новую версию продукта NAKIVO Backup & Replication v10. Напомним, что мы писали о версии NAKIVO B&R 7.2 почти три года назад. С тех пор функциональность продукта существенно улучшилась, и это теперь полноценное Enterprise-решение.

Давайте посмотрим, что нового появилось в десятой версии NAKIVO Backup & Replication:

• Поддержка vSphere 7 - теперь эта платформа полностью поддерживается одновременно с поддержкой и более ранних версий. Администраторы могут получить все новые возможности обновленной платформы, включая резервное копирование, репликацию, гранулярное восстановление и функции disaster recovery.
• Резервное копирование в хранилища Wasabi Hot Cloud Storage - теперь создание бэкапов в блочном облачном хранилище полностью поддерживается со стороны NAKIVO B&R v10. Напрямую в облако Wasabi можно передавать резервные копии виртуальных машин, физических серверов, баз данных Oracle, а также инстансы Amazon EC2. При мгновенном прямом восстановлении поддерживаются не только виртуальные машины, но и файлы и папки, а также объекты приложений.
• Восстановление Physical-to-Virtual (P2V) - теперь с помощью десятой версии NAKIVO вы можете перенести свои физические машины в виртуальную среду. Создание виртуальной машины происходит через легковесные агенты в физических ОС. Также можно и восстанавливать резервные копии физических систем напрямую в облако.
• Бэкап десктопов Linux - теперь можно производить резервное копирование рабочих станций с Ubuntu Linux на борту так же, как это делается и для физических серверов. Все операции делаются в едином дэшборде.
• Улучшения пользовательского интерфейса - централизованный дэшборд теперь позволяет контролировать все аспекты резервного копирования и более интуитивно выполнять операции.

Скачать NAKIVO Backup & Replication v10 можно по этой ссылке.

Некоторые из вас знают, что есть такое решение VMware vRealize Network Insight (vRNI), которое предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vSphere.

Администраторам виртуальной инфраструктуры часто приходится делать копии различных ее управляющих компонентов, в том числе vRNI. Сейчас VMware рекомендует делать резервную копию конфигурации vRNI на уровне всей виртуальной машины (см. KB 55829). Рекомендуется выключить ВМ с vRNI, скопировать ее целиком, а потом включить снова - это единственный поддерживаемый способ на данный момент.

Martijn Smit опубликовал интересный пост о том, что на самом деле у vRNI есть способ резервного копирования и восстановления конфигурации через API, для которого есть специальный API endpoint по пути /settings/backup:

Если посмотреть внутрь, то там можно увидеть вполне работоспособный механизм бэкапа конфигурации vRNI:

Используя API endpoint /api/ni/settings/backup, вы можете создать резервную копию конфигурации vRNI и перенаправить ее по SSH или FTP на бэкап-сервер в виде tar-файла со следующим содержимым:

Большинство этих файлов человекочитаемы, если вы откроете их в текстовом редакторе. Там находятся копии настроек приложений, объектов pinboards, data sources, сохраненный поиск, системные настройки (Syslog, SMTP и т.п.), пользовательские конфигурации и многое другое.

Для работы с конфигурациями vRNI через API Martijn сделал модуль PowervRNI. Вот пример использования сценария резервного копирования:

PS # $backupSchedule = @{ "enable" = $true; "schedule_period" = "DAILY"; "minute" = 30; "hour" = 12; "day_of_week" = 1 }

  PS # $sshServer = @{ "server_address" = "my-ssh-server"; "port" = 22; "username" = "vrni-backups"; "password" = "VMware1!"; "backup_directory" = "/home/vrni-backups/"; "backup_file_name" = "vrni-backup.tar" }

PS # Set-vRNIBackup -RunNow $true -BackupSchedule $backupSchedule -SSHServer $sshServer
config_filter

  -------------

  @{applications=True; snmp=True; smtp=True; data_sources=True; analytics_thresholds=True; analytics_outliers=True; events=True; syslog=True; pinboards=True; ldap=True; vidm=True; user_data=True; user_preferences=True; physical_subnet_v…
PS # Get-vRNIBackupStatus
status status_updated_timestamp

  ------ ------------------------

  IN_PROGRESS 1595425176027 Smit

  PowervRNI
  

Переменная $backupSchedule содержит в себе расписание резервного копирования, в примере выше она установлена на 12:30 (формат 24h) каждого дня.

Источник.

Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:

Paul Braren написал полезную инструкцию у себя в блоге о том, как решить эту проблему.

Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.

Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):

Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

После этого нужно найти id датастора следующей командой:

Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:

DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;

При выполнении второй операции вы получите следующую ошибку:

ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".

Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.

Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)

На блогах VMware вышла отличная статья про безопасность виртуальных машин и виртуальной инфраструктуры VMware vSphere в целом, расскажем ниже ее основные моменты.

Как известно, одним из действенных способов атак на виртуальную инфраструктуру vSphere является проведение злоумышленником вредоносных действий из виртуальной машины, которая потом уничтожается, часто не оставляя следов и записанных действий. Еще один интересный способ со спецификой виртуализации - украсть виртуальную машину (например, контроллер домена) и ковыряться в ней уже в своей песочнице, чтобы вытащить нужную информацию.

Для предотвращения подобных типов угроз есть такие специализированные средства, как VMware Carbon Black, vRealize Log Insight и vRealize Network Insight, но базовые требования информационной гигиены нужно соблюдать и на уровне гостевых систем.

На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:

• C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe (Windows)
• /usr/bin/vmware-toolbox-cmd (Linux)

Само собой приведенные ниже рекомендации - это руководство для параноиков (но, как говорит Эндрю Гроув - выживают только параноики), потому что безопасность, как вы знаете - это всегда компромисс между удобством и маниакально-призрачным ощущением защищенности.

И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:

1. Отключить синхронизацию времени с хостом VMware ESXi

Время - очень важная категория в контексте безопасности. Оно важно для логов, для синхронизации событий аутентификации и прочего. По-хорошему, гостевая ОС должна получать время от NTP-сервера, а не от ESXi, который может быть скомпрометирован. Если вы сомневаетесь, что у вас настроено иначе, нужно принудительно отключить синхронизацию времени с хостом. Делается это следующей командой:

VMwareToolboxCmd.exe timesync disable

2. Отключить автообновление VMware Tools

Если у вас в компании принято, что рабочий процесс обновления системных компонентов должен быть унифицирован и контролироваться из одной точки, то можно отключить автоапдейт VMware Tools. Делается это так:

VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false

3. Отключить возможность кастомизации ОС при клонировании

Такая опция позволяет изменять параметры виртуальной машины и гостевой системы, что может быть выгодно злоумышленнику. Отключить кастомизацию ВМ можно следующей командой:

VMwareToolboxCmd.exe config set deployPkg enable-customization false

4. Контроль над информацией, предоставляемой через Appinfo

Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:

VMwareToolboxCmd.exe config set appinfo disabled true

5. Отключить Guest Operations (оно же Invoke-VMScript)

Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:

VMwareToolboxCmd.exe config set guestoperations disabled true

6. Отключение ненужных компонентов

Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".

Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.

Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.

Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.

Собственно, сам скрипт (исходник доступен тут):

Комментарии от автора:

После выполнения сценария нужно будет, само собой, расширить соответствующий раздел гостевой системы. Современные версии Windows и Linux могут раскатывать существующий раздел на весь размер физического устройства даже без перезагрузки машины.

Пример использования сценария:

PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.

На днях компания VMware обновила свое решение для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Теперь App Volumes 4.1 (она же официально версия 2006) может работать еще и в облачной среде Horizon Cloud on Azure (подробнее об этом здесь).

Давайте посмотрим, что нового и интересного есть в обновлении продукта:

• При изменении назначений (assignments) возникает диалоговое окно с обзором изменений, которые будут сделаны. Если они обновляются, то теперь не требуется удалять прошлые назначения, они просто обновляются.
• Администраторы могут ограничить доставку пакетов приложений на компьютеры с определенным префиксом в имени машины.
• App Volumes Manager теперь позволяет использовать единый рабочий процесс для сторонних пакетов и запускать их параллельно с нативными. Пакеты MSIX с привязанными VHD можно использовать средствами утилиты App Volumes Packaging Utility.
• Поддержка LDAP Channel Binding and LDAP Signing.
• Изменение версионирования - теперь это не номер версии 4.1, а год и месяц, то есть текущая версия - 2006. Для агента и App Volumes Manager версия 4.1 останется.
• Улучшения производительности при логине пользователя.
• Функции rolling upgrade опять вернулись - теперь можно обновить один из App Volumes Manager, когда остальные продолжают работать.
• Добавлена поддержка Microsoft Office 2019, Microsoft SQL Server 2019 и Microsoft Windows 10, version 2004.
• Обновления документации.

Скачать VMware App Volumes 2006 можно по этой ссылке.

При описании новых возможностей VMware vSphere 7 мы рассказывали о функциях платформы, появившихся в результате приобретения VMware компании Bitfusion. Эти возможности позволяют оптимизировать использование графических процессоров GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может применяться для рабочих нагрузок задач AI/ML (например, для приложений, использующих PyTorch и/или TensorFlow).

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети.

Технология эта называлась FlexDirect, теперь это продукт vSphere Bitfusion:

На днях это продукт стал доступен для загрузки и использования в онпремизных инфраструктурах.

Ключевыми особенностями vSphere Bitfusion являются:

• Возможность динамической привязки GPU к любой машине в датацентре, по аналогии с тем, как вы привязываете к ней хранилище.
• Возможность использования ресурсов GPU как одной машине, так и разделения его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU между потребителями.
• Возможность предоставления доступа как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.
• Передача инструкций к серверным машинам и обратно на уровне CUDA-вызовов. То есть это решение не про передачу содержимого экрана как VDI, а про высокопроизводительные вычисления.
• Прозрачная интеграция - с точки зрения приложений менять в инфраструктуре ничего не нужно.

Для управления инфраструктурой доставки ресурсов GPU используется продукт vSphere Bitfusion Manager, который и позволяет гибко распределять ресурсы между потребителями. Раньше он выглядел так:

Теперь же он интегрирован в vSphere Client как плагин:

Архитектура Bitfusion позволяет разделить виртуальную инфраструктуру VMware vSphere на ярусы: кластер GPU, обсчитывающий данные, и кластер исполнения приложений пользователей, которые вводят данные в них и запускают расчеты. Это дает гибкость в обслуживании, управлении и масштабировании.

С точки зрения лицензирования, решение vSphere Bitfusion доступно как аддон для издания vSphere Enterprise Plus и лицензируется точно так же - по CPU. Для других изданий vSphere, увы, этот продукт недоступен.

Скачать vSphere Bitfusion можно по этой ссылке. Документацию можно найти на странице продукта. Также Bitfusion интегрирован с инфраструктурой vSphere with Kubernetes, о чем можно почитать вот в этом документе.

Многие администраторы VMware vSphere знают, что иногда в виртуальной инфраструктуре может возникнуть ситуация APD (All Paths Down). Это состояние, когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация.

Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.

При настройке механизма VMware vSphere HA на уровне кластера у вас есть следующие опции реагирования на такую ситуацию:

• Disable - ничего не делать с виртуальными машинами
• Issue Event - ничего не делать, но сгенерировать событие
• Power Off / Restart – Conservative
• Power Off / Restart – Aggressive

Последние два варианта - Conservative и Aggressive - не очень ясны. Отличие между ними заключается в том, что в консервативном (Conservative) сценарии механизм VMCP (VM Component Protection) сработает только тогда (выключит ВМ), когда убедится, что виртуальные машины могут быть перезапущены на других хостах кластера. В этом случае ESXi убеждается, что связь с другими хостами есть и у них есть доступ к хранилищу ВМ.

В случае политики Aggressive виртуальные машины будут выключены в любом случае, даже если хост не может убедиться, что они могут быть перезапущены на других хостах кластера. Это может произойти в случае полного распада сети, когда хосты ESXi не видят друг друга по сетям сервисной консоли и сети хранения данных. Но если ESXi точно знает, что машины не перезапустятся на других хостах, то и в случае Aggressive он не будет выключать ВМ. То есть выбор всегда делается в пользу наибольшей доступности виртуальных машин.

Иногда, конечно, лучше убить процесс виртуальной машины, если вы попадаете в ситуацию неопределенности в кластере. Ведь лучше выключить машину, чем иметь от нее подтверждения записи на диск, хотя фактически этой записи не происходит. Если вы хотите минимизировать вероятность поддержания таких ВМ в рабочем состоянии для приложений, когда их хранилище отвалилось полностью, вы можете добавить вот такую настройку vSphere HA для всего кластера:

das.restartVmsWithoutResourceChecks = true

Источник.

Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.

На сайте проекта VMware Labs вышло очередное полезное обновление - утилита HCIBench версии 2.4. О прошлых версиях HCIBench мы писали тут и тут. Напомним, что она позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду Vdbench, какие действия необходимо выполнить в кластере хранилищ.

Посмотрим, что нового в HCIBench 2.4:

• Исправлена частая ошибка при указании хоста во время развертывания
• Поддержка варианта запуска easy run для "растянутого" (stretched) кластера
• Исправлена ошибка в отображении таймзоны в PDF-отчете, также в отчет было добавлено немного полезной информации о vSAN
• Установка testname и testcase как переменных фреймворка Grafana
• Добавлена информация о CPU workload на страницу конфигурации модели fio
• Обновлен пакет rbvmomi - теперь он поддерживает vSphere 7.0+
• Улучшенные дашборды компонентов fio и vdbench graphite

Скачать HCIBench 2.4 можно по этой ссылке. Документация доступна тут.

Многие администраторы платформы VMware vSphere после выхода седьмой версии продукта обнаружили, что ESXi 7.0 больше не хочет устанавливаться на старом оборудовании. Так происходит с каждой версией VMware vSphere - старые драйверы убирают, новые добавляют - это нормальный цикл жизни и развития продуктов. Например, больше не поддерживаются следующие процессоры:

• Intel Family 6, Model = 2C (Westmere-EP)
• Intel Family 6, Model = 2F (Westmere-EX)

Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.

Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:

Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:

allowLegacyCPU=true

Далее для установки выбрали USB-диск и начали установку ESXi на него:

После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:

Теперь нужно сделать так, чтобы данный параметр добавлялся при каждой загрузке ESXi. Сначала включим сервисы командной строки ESXi и удаленного доступа по SSH. Для этого нужно запустить службы TSM и TSM-SSH на хосте ESXi:

Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:

find / -name "boot.cfg

Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:

Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.

С помощью команды cat выведите содержимое отредактированных файлов, чтобы убедиться, что параметры загрузки у вас будут сохраняться:

Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:

Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:

Как вы знаете, в продуктовой линейке VMware есть два решения, предназначенных для виртуализации сетей и централизованного управления сетевым взаимодействием виртуальных машин на уровне всего датацентра - это продукты NSX-T и NSX-V.

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). Решение NSX-V разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба решения могут быть использованы под одной лицензией, что дает пользователям гибкость при выборе нужного типа развертывания.

(картинка отсюда)

Давайте взглянем на сравнительную таблицу двух версий решений VMware NSX, где собраны основные ключевые отличия:

Ну и вот обзорное видео об основных отличиях NSX-T и NSX-V:

На сайте проекта VMware Labs очередное обновление - новая версия утилиты vSphere Software Asset Management Tool 1.2. Напомним, что средство vSAM предназначено для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - инвентаря и доступных лицензий. О прошлой версии vSAM мы писали вот тут (там появилась поддержка vSphere 7).

Посмотрим на новые возможности vSAM 1.2:

• Отображение в отчете информации об инфраструктуре кластеров хранилищ vSAN
• Можно открытым текстом выводить лицензионные ключи в отчете, если выставлена соответствующая опция
• В отчет добавлена таблица License Inventory

Скачать vSphere Software Asset Management Tool 1.2 можно по этой ссылке.

Если вы следите за обновлениями VMware vSphere 7, то наверняка знаете, что не так давно уже выходили минорные обновления vCenter 7.0 Update 0a и vSphere with Kubernetes.

На днях VMware выпустила еще один небольшой апдейтик - vCenter 7.0.0b (на момент написания заметки дистрибутив еще недоступен для скачивания).

Давайте посмотрим, что там появилось нового:

• Новые алармы: vCenter Server 7.0.0b получил еще один аларм для vCenter Server Appliance, который срабатывает в случае, когда состояние репликации меняется на READ_ONLY. Аларм гасится, если состояние возвращается в Normal. С помощью этого аларма легко обнаружить проблемы в репликации между узлами vCenter на одной или нескольких площадках.
• C vCenter Server 7.0.0b можно использовать кнопку "Show only rollup updates", позволяющую отфильтровать и выбрать патчи, которые вы хотите включить в бейслайн для vSphere Lifecycle Manager. Кнопка доступна на вкладке Updates панели Lifecycle Manager. Также эта опция доступна в мастере создания нового бейслайна.
• Решено несколько проблем и исправлены некоторые ошибки. Посмотреть информацию о них можно тут.
• Про обновления движка VMware vSphere with Kubernetes рассказано здесь.

Скачать VMware vCenter 7.0.0b в составе vSphere 7 можно по этой ссылке.

Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.

При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:

Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.

Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.

Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).

Эти блоки и нужно скопировать во время паузы FSR:

До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:

Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:

Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:

Компания VMware недавно выпустила интересную бесплатную книгу "Micro-segmentation for Dummies Guide, 2nd Edition".

Те из вас, кто использует решение для сетевой виртуализации и агрегации трафика VMware NSX и средство обеспечения сетевой безопасности vRealize Network Insight, знают о таком подходе как микросегментация. С помощью него можно управлять сетевыми политиками на базе контекстов приложений - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности).

Данная модель позволяет контролировать сетевой трафик на более гранулярном уровне, чем на уровне виртуальных машин и модулей Virtual Appliance, а также существенно повышает безопасность коммуникаций за счет принципа выдачи наименьших привилегий и фаерволлинга на уровне микросегментов.

Из книжки вы узнаете:

• Как разработать архитектуру защищенного датацентра на базе сетевой виртуализации и фаерволлинга на уровне рабочих нагрузок.
• Как микросегментация позволяет предотвратить распространение скрытых угроз в инфраструктуре датацентра.
• Топ 10 бизнесовых и функциональных преимуществ микросегментации.

Скачать книгу "Micro-segmentation for Dummies Guide, 2nd Edition" можно по этой ссылке.

Часто при создании отладочного пакета vCenter Appliance log bundle на сервере VMware vCSA (он нужен для техподдержки VMware и траблшутинга) администраторы сталкиваются с недостатком свободного места в разделе /storage/log. Это бывает даже, когда у вас есть 5 ГБ свободного места - да, логи в рамках одной выгрузки могут занимать и больше!

Чтобы найти прошлые логи и удалить их с сервера vCSA, нужно зайти на него по SSH и перейти в категорию /storage/log. Далее найти логи можно командой:

find . -iname *.tgz

В соответствующих папках будут лежать эти файлы журналов. Удалить их можно стандартной командой:

rm *.tgz

После этого нужно перезапустить управляющие службы vCSA:

service-control --stop --all
service-control --start --all

С этого момента место будет считаться очищенным, и вы сможете создать log bundle в целях поиска источника проблемы и ее решения.

На портале VMware Learning появились новые лабы (они же Hands-on Labs), которые посвящены новой версии платформы VMware vSphere 7:

Напомним, что лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.

На данный момент доступны следующие лабы:

• HOL-2111-01-SDC – VMware vSphere – What’s New
• HOL-2111-02-SDC – VMware vSphere – Advanced Topics
• HOL-2111-03-SDC – VMware vSphere – Security Getting Started

В этих лабораторных работах содержится около трех часов контента, с помощью которого вы сможете узнать обо всех нововведениях vSphere 7 в деталях. Скоро также обещают и лабы по vSphere 7 with Kubernetes, что будет очень полезно, так как многие пользователи не могут попробовать контейнеризованные приложения в своей виртуальной инфраструктуре.

Также уже довольно давно доступна лаба VMware Cloud Foundation 4 Hands-on Lab - напомним, что архитектура VCF 4 также построена на базе VMware vSphere 7.

Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов (Partition Layout), которые произошли в VMware ESXi 7.

Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.

Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.

В VMware vSphere 6.x структура разделов выглядела следующим образом:

Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.

В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:

Теперь в ESXi 7 есть следующие 4 раздела:

• System boot - хранит boot loader и модули EFI. Формат: FAT16.
• Boot-banks (2 штуки) - системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
• ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.

Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.

В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:

Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.

Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).

Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:

В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:

Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):

Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.

Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.

ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:

• Boot media размером минимум 8 ГБ для устройств USB или SD
• 32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
• Boot device не может быть расшарен между хостами ESXi

Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.

Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...